Systems and methods for analyzing telematics data to determine a driver on a shared trip

ABSTRACT

A technical design solution for classifying users as potential drivers traveling in a vehicle based upon a combination of gathered data during a shared trip and historical data. Data gathered would include, at the least, overlapping time and distance of users to be classified as potential drivers. Shared trip scenarios, where a driver is identified, include (1) two or more users share a complete trip from beginning to end; (2) two or more users share the beginning of a trip, at least one user is dropped off, thereby ending their trip, and the other user continues driving; (3) two or more users share the end of a trip, where at least one user is picked up during the shared trip; and (4) one user picks up at least one other user during a trip, thereby creating a shared trip, and drops off the at least one other user to a different location, then heads to a final location. Driver identification is performed based upon the real-time gathering of data, which is then analyzed based upon and in view of historical data.

FIELD OF THE INVENTION

The present disclosure relates to analyzing driving telematics data todetermine driving characteristics of a driver, and, more particularly,to systems and methods for determining an actual driver of a vehicle ascompared to other passengers in the vehicle based at least in part uponpositioning data, time data, and other telematics data.

BACKGROUND

Vehicle insurance often essentially provides financial protectionagainst physical damage or bodily injury caused by a vehicular accident.Other financial protections may also be provided, such as vehicle theftor damage caused by natural disasters. Conventionally, car insurancerates, or premiums, are typically determined based upon a driver's ageand driving history, car make, model, and year, among a myriad of otherfactors.

Some vehicle insurance companies provide premium discounts to driversthat exhibit safe driving characteristics. Discounts are typicallycalculated based upon annual mileage and basic driving characteristics,such as braking, speed, time of day travel, acceleration rates, and fastcornering. Vehicles may be equipped with navigation systems capable oftracking driving characteristics. Also, mobile computing devices ofdrivers of vehicles may be used to gather certain telematics data. Forexample, a mobile computing device associated with a driver may trackthe driver's driving behavior during vehicle operation. Tracking istypically done via one or more integrated sensors or other devices, suchas geo-spatial positioning modules, accelerometers, and gyroscopes.However, problems may arise when an insurance customer is misclassifiedas the driver of the vehicle when the insurance customer is actuallyriding as a passenger in a vehicle.

Satellite navigation systems such as global positioning system (GPS)utilize satellites to provide geo-spatial positioning for a variety ofapplications. A GPS-equipped device may provide a location of a mobilecomputing device with respect to, for example, a geographic coordinatesystem and/or geographic landmarks (e.g., streets, political entities,points of interest, etc.). Current GPS-equipped devices are generallynot capable of determining the exact location of the device, but ratherprovide an estimate of the device's current location subject to somedegree of error. For example, atmospheric effects (e.g., ionosphericdelay) and/or artificial interference a presence of metal and/orelectromagnetic devices) may introduce error to a GPS-baseddetermination of location.

Some systems may benefit from an ability to identify an actual driver ofa vehicle for a shared trip using mobile computing devices carried byusers in the vehicle in combination with other statistics. Identifyingthe driver may be useful in computer applications that utilizetelematics data to assess the driver of the vehicle, such as forinsurance purposes. In such applications, the driver of the vehicle fora trip must be distinguished from passengers, so that telematics datacaptured during the trip may be used to assess how the driver is drivingand not incorrectly assign the driver's driving characteristics to thatof the passengers. However, currently available GPS technology lacks theprecision to make an identification of an actual driver of a vehiclebased upon measured geographic coordinates alone.

BRIEF SUMMARY

The present embodiments may relate to, inter alia, systems and methodsfor assigning a shared trip to a single driver of a vehicle for aparticular trip. Some embodiments of the present disclosure may use, forexample, a combination of statistical data (e.g., trip start/stop times,shared distance times, etc.), geographical location measurements made bya global positioning system (GPS), and historical trip data to identifyand assign at least one user as a driver of a vehicle during a sharedtrip. In some embodiments, a usage-based insurance (UBI) policy may beapplied to the identified driver of the vehicle.

In one aspect, a driver identification (DI) computing device having atleast one processor in communication with a memory device may beprovided. The at least one processor may be configured to: associate afirst user with a first user device; associate a second user with asecond user device; receive, from the first user device, a firstplurality of measurements periodically captured by the first user deviceduring a first trip; receive, from the second user device, a secondplurality of measurements periodically captured by the second userdevice during a second trip; identify a shared trip based upon thecaptured first and second plurality of measurements; and determine,based upon the captured first and second plurality of measurements, adriver of a vehicle, in response to the first and second trip being ashared trip.

The at least one processor may be further configured to: calculate atime and distance for each of the first trip and the second trip inresponse to determining that the first trip has a start time or end timethat overlaps with the end time or start time of the second trip;calculate an overlapping time and distance between the first trip andthe second trip; and calculate a distance shared between the first tripand the second trip.

The at least one processor may be further configured to, for identifyinga shared trip: classify the first trip and the second trip as a sharedtrip in response to determining that the overlapping distance is lessthan the distance of the first trip or the second trip.

The DI computing device may further include wherein the higher drivingprobability is based at least in part on historical data stored in auser profile of the first or second users.

The DI computing device may further include wherein each of the firstplurality of measurements and each of the second plurality ofmeasurements includes timing data, geographical location data, andtelematics data.

The DI computing device may further include wherein the first pluralityof measurements and the second plurality of measurements are collectedby one or more sensors attached to a vehicle, the first user device, thesecond user device, or a combination thereof. The processor of the DIcomputing device may include additional, less, or alternatefunctionality, including that discussed elsewhere herein.

In another aspect, a computer-based method for designating a driver of ashared trip between two or more users may be provided. Thecomputer-based method may include collecting, by a plurality of userdevices, a plurality of measurements for a plurality of trips;receiving, at a driver identification (DI) computing device, theplurality of measurements; and designating, by the DI computing device,a driver based upon the plurality of measurements.

The method may further include storing the plurality of measurements ina storage device in communication with the DI computing device;associating the plurality of measurements with respective users of thetwo or more users; and creating a user profile for each of the two ormore users based upon the plurality of measurements. The computer-basedmethod may include additional, less, or alternate functionality,including that discussed elsewhere herein.

In yet another aspect, at least one non-transitory computer-readablestorage media having computer-executable instructions embodied thereonmay be provided that, when executed by at least one processor, thecomputer-executable instructions cause the processor to: receive tripdata from a plurality of user devices, wherein each user device isassociated with a user of a plurality of users; identify a first user ofthe plurality of users having trip data that overlaps with trip data ofa second user of the plurality of users; classify at least a portion ofthe trip data of the first and second users as a shared trip; anddesignate at least one of the first and second users as a driver of theshared trip. The computer-executable instructions may includeadditional, less, or alternate actions, including those discussedelsewhere herein.

Advantages will become more apparent to those skilled in the art fromthe following description of the preferred embodiments which have beenshown and described by way of illustration. As will be realized, thepresent embodiments may be capable of other and different embodiments,and their details are capable of modification in various respects.Accordingly, the drawings and description are to be regarded asillustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The Figures described below depict various aspects of the systems andmethods disclosed therein. It should be understood that each Figuredepicts an embodiment of a particular aspect of the disclosed systemsand methods, and that each of the Figures is intended to accord with apossible embodiment thereof. Further, wherever possible, the followingdescription refers to the reference numerals included in the followingFigures, in which features depicted in multiple Figures are designatedwith consistent reference numerals.

There are shown in the drawings arrangements which are presentlydiscussed, it being understood, however, that the present embodimentsare not limited to the precise arrangements and are instrumentalitiesshown, wherein:

FIG. 1 is a block diagram illustrating an example driver identification(DI) computer system in accordance with an example embodiment of thepresent disclosure.

FIG. 2 is a block diagram of an example client computing device that maybe used with the DI computer system illustrated in FIG. 1.

FIG. 3 is a block diagram of an example server system that may be usedwith the DI computer system illustrated in FIG. 1.

FIG. 4 is a flowchart showing an example method for implementing driverdesignation of a vehicle for a shared trip using the DI computer systemillustrated in FIG. 1.

FIGS. 5A and 5B are flowcharts showing an example method for classifyingnew trip data received by the DI computer system illustrated in FIG. 1.

FIG. 6 illustrates a diagram of components of one or more exemplarycomputing devices that may be used in the DI computer system illustratedin FIG. 1.

The Figures depict preferred embodiments for purposes of illustrationonly. One skilled in the art will readily recognize from the followingdiscussion that alternative embodiments of the systems and methodsillustrated herein may be employed without departing from the principlesof the invention described herein.

DETAILED DESCRIPTION OF THE DRAWINGS

The subject matter will now he descried in detail for specificembodiments. It is understood that the described embodiments areintended only as illustrative examples and are not to he limitedthereto.

The present embodiments may relate to, inter cilia, systems and methodsfor identifying a driver of a vehicle for a shared trip. In someembodiments, the systems and methods described herein may includereceiving measurements of geographic location and other telematics data(e.g., acceleration, velocity, orientation, etc.) from a plurality ofuser devices (e.g., mobile computing devices) or other sensors presentin the vehicle during trips of each respective user device. Furtheranalysis of this received data may reveal that two or more of theplurality of user devices may be part of a shared trip. For example,overlapping times and geographical locations of trips taken by some ofthe plurality of user devices may be classified as occurring during thesame trip, and therefore regarded as a shared trip between the userdevices and users associated with the user devices. In one exampleembodiment, the process may be performed by a driver identification (DI)computing device, which may be part of a DI computer system. Collectedmeasurements may be analyzed by the DI computing device to identify ashared trip and the users associated with the shared trip. Further dataanalysis may be performed using different algorithms to designate atleast one of the identified users as an actual driver of a shared trip.In some embodiments, the user devices may have stored thereon anapplication (e.g., an insurance application) that is configured togenerate and store driving characteristics (e.g., braking, speed, timeof day travel, acceleration rates, and fast cornering) of the driver.The driving characteristics may be used in determining insurance ratesfor users, so it may be needed that driving characteristics only beassociated with the driver, not passengers, of the vehicle during eachtrip.

In some embodiments, the systems and methods described herein mayadditionally or alternatively include receiving, along with themeasurements of geographic coordinates, telematics data (e.g.,accelerometer and/or gyroscope measurements), and using the measuredgeographic coordinates and telematics data to calculate a probabilityfor each user device that the user device corresponds to the driver ofthe vehicle.

In some embodiments, the systems and methods described herein mayadditionally or alternatively include receiving, along with themeasurements of geographic coordinates, historical data (e.g., pasttrips driven, time of day statistics), and using the measured geographiccoordinates and historical data to calculate a probability for each userdevice that the user device is associated with the driver of thevehicle.

In some embodiments, the systems and methods described herein mayadditionally or alternatively include processing, along with themeasurements of geographic coordinates, statistical data (e.g.,overlapping time and distance data of route segments shared between twoor more user trips), to classify multiple user trips as a shared tripand to calculate a probability for each user device that the user deviceis associated with the driver of the vehicle.

In some embodiments, the systems and methods described herein mayadditionally or alternatively include processing a combination of one ormore of measurements of geographic coordinates, historical data, andstatistical data to identify shared trips and calculate a probabilityfor each user device that the user device is associated with the driverof the vehicle.

As described below, the systems and methods described herein determine aprobability that a user device is associated with the actual driver ofthe vehicle as opposed to one of the passengers of the vehicle during ashared trip in accordance with certain scenarios. As used herein,“driver” refers to a user actually driving a vehicle, and “passenger”refers to any user that is not driving and present in a vehicle. By sodoing, the driver of the vehicle for a particular shared trip may beidentified.

In some example embodiments, the systems and methods described hereinmay be used to identify and designate at least one user as a driver in aplurality of possible scenarios. Further, the systems and methods maysegment trips and identify sub-trips. For example, a first user maytravel a certain distance between points A, B, and C and a second usermay travel a portion of this distance, such as between point B and pointC. In this non-limiting example, the second user completes only aportion of the entire trip, a “sub-trip,” and the first user completesthe entire journey from start to finish, the “trip.” The trip mayinclude a plurality of sub-trips, or segmented portions of the entiretrip from start to finish that may vary in length and number of users inthe vehicle. In some example embodiments described herein, differenttrips between users may have overlapping times, and the sub-trips mayhave different starting and ending times. In these instances, sub-tripsare determined and analyzed to designate a driver amongst a plurality ofusers. In some embodiments, a shared trip may be identified as any tripor sub-trip shared between at least two users (e.g., as determined byGPS data, timing data, latitude-longitude data, distance data, and/ortelematics data of the user devices associated with the users).

In some example embodiments, the systems and methods may be used toclassify a new trip as part of a shared trip among other user trips. Asnew trip data is received, a determination may be made as to whether ornot the new trip data should be associated with a previously submittedtrip associated with another user. If overlapping data is found betweentwo or more logged trips, a shared trip may be identified. Once a sharedtrip is identified, it may then be needed to adequately determine amongthe users associated with the shared trip, the driver of the vehicleduring the shared trip. New trip data may include, inter cilia, UPSdata, timing data, latitude-longitude data, distance data, telematicsdata, or the like. Further, for example, a database of previously loggedtrips may be queried, such as a dataset containing logged trips from thepast 30 days.

In some example embodiments, the systems and methods may be used toimplement a usage-based insurance platform. In usage-based insurancepolicies of usage-based insurance platforms, insurance premiums maycorrespond to driving behaviors and/or characteristics of users. Theinsurance premiums may be based in part upon telematics data collectedfrom a user device associated with the user. For example, if telematicsdata associated with a user show that the user has generally safedriving behaviors and characteristics, the insurance premium for theuser may be low. Further, if telematics data associated with a user showthat the user has generally hazardous and unsafe driving behaviors andcharacteristics, the insurance premium for the user may be high. It isthus advantageous to determine when a user is actually driving a vehicleand when the user is merely a passenger of a vehicle. By identifying adriver of a vehicle for a shared trip, the systems and methods enabletelematics data collected for the shared trip to be applied in analyzingthe driving behaviors and characteristics of only the identified driver.

At least one of the technical problems address by this system mayinclude: (i) inability of a UPS device to provide a geographic locationmeasurement sufficiently precise to be used to identify the driver of avehicle; (ii) inability of a computing device to automatically designatea driver of a vehicle based upon telematics data; (iii) inefficiency inidentifying a driver of a vehicle due to an inability of a computingdevice to automatically identify a driver of a vehicle based upontelematics data; (iv) inability of a computing device to automaticallydesignate a driver of a vehicle among a pool of possible drivers duringa shared trip; and (v) inefficiency in providing usage-based insurancecoverage due to an ability of a computing device to automaticallydesignate the driver of a vehicle in order to apply telematics dataassociated with a shared trip to a usage-based insurance policyassociated with the driver.

A technical effect of the systems and processes described herein may beachieved by performing at least one of the following steps: (i)receiving, from a first user device, a first plurality of measurementsperiodically captured at the first user device during a trip taken by avehicle; (ii) receiving, from a second user device, a second pluralityof measurements periodically captured at the second user device during atrip taken by a vehicle; (iii) determining, based upon the firstplurality of measurements and the second plurality of measurements, thatthe first user device and the second user device are within the samevehicle during the trip; and (iv) designating at least one of the userdevices as being associated with a driver of the vehicle during the tripbased upon the first and second plurality of received measurements.

The technical effect achieved by this system may be at least one of: (i)ability of a GPS device and a timing mechanism to provide measurementssufficiently precise to be used to identify the driver of a vehicle;(ii) ability of a computing device to automatically identify a driver ofa vehicle based upon the provided measurements; (iii) increasedefficiency in identifying a driver of a vehicle due to an ability of acomputing device to automatically identify a driver of the vehicle basedupon the provided measurements; and (iv) increased efficiency inproviding usage-based insurance coverage due to an ability of acomputing device to automatically identify the driver of a vehicle inorder to apply telematics data associated with the trip to a usage-basedinsurance policy associated with the driver.

EXEMPLARY COMPUTER SYSTEM FOR DESIGNATING A DRIVER

FIG. 1 depicts an example driver identification (DI) computer system100. DI computer system 100 may include a DI computing device 102 (alsoreferred to herein as DI server or DI computer device). DI computingdevice 102. may include a database server 106. DI computing device 102may be in communication with, for example, one or more of a database108, one or more user devices 110, and a client computing device 112.User devices 110 may be, for example, mobile computing devices. In someembodiments, DI computing device 102 may communicate with additionaluser devices substantially similar to user devices 110. In someembodiments, client computer device 112 may be associated with, forexample, an insurer providing a usage-based insurance (UBI) policy tousers associated with user devices 110.

In the exemplary embodiment, user devices 110 may be computers thatinclude a web browser or a software application, which enables userdevices 110 to access remote computer devices, such as DI computingdevice 102, using the Internet or other network. More specifically, userdevices 110 may be communicatively coupled to DI computing device 102through many interfaces including, but not limited to, at least one ofthe Internet, a network, such as the Internet, a local area network(LAN), a wide area network (WAN), or an integrated services digitalnetwork (ISDN), a dial-up-connection, a digital subscriber line (DSL), acellular phone connection, and a cable modem. User devices 110 may beany device capable of accessing the Internet including, but not limitedto, a desktop computer, a laptop computer, a personal digital assistant(PDA), a cellular phone, a smartphone, a tablet, a phablet, wearableelectronics, smart watch, or other web-based connectable equipment ormobile devices. In the exemplary embodiment, user devices 110 may beassociated users, and the users may be drivers or passengers of avehicle.

Client computer device 112 may be communicatively coupled with DIcomputing device 102. In some embodiments, client computer device 112may be associated with, or is part of a computer network associated withan insurance provider, or in communication with the insurance provider'scomputer network (not shown). In other embodiments, client computerdevice 112 may be associated with a third party and is merely incommunication with the insurance provider's computer network. Morespecifically, client computer device 112 is communicatively coupled tothe Internet through many interfaces including, but not limited to, atleast one of a network, such as the Internet, a local area network(LAN), a wide area network (WAN), or an integrated services digitalnetwork (ISDN), a dial-up-connection, a digital subscriber line (DSL), acellular phone connection, and a cable modem. Client computer device 112may be any device capable of accessing the Internet including, but notlimited to, a desktop computer, a laptop computer, a personal digitalassistant (PDA), a cellular phone, a smartphone, a tablet, a phablet,wearable electronics, smart watch, or other web-based connectableequipment or mobile devices.

Database server 106 may be communicatively coupled to database 108 thatstores data. In one embodiment, database 108 may include data from userdevices 110, data regarding the users associated with user devices 110,insurance policies relating to client computer devices 112, etc. In anexample embodiment, database 108 may be stored remotely from DIcomputing device 102. In some embodiments, database 108 may bedecentralized.

DI computing device 102 may receive geographic coordinate data (e.g.,global positioning system (GPS) data), time measurement data, and/ortelematics data from user devices 110 and/or other sensors (e.g.,sensors associated with a vehicle). User devices 110 may includecomponents for capturing and generating data including a GPS device 114,an accelerometer 116, a gyroscope 118, and/or any other devicecomponents for capturing and generating data. DI computing device 102may use the received geographic coordinate data (e.g., from GPS device114 of user devices 110) and telematics data (e.g., from user devices110) to determine a location and timing of the determined location ofone user device 110 with respect to other user devices 110.

User devices 110 may be equipped with, for example, GPS device 114. GPSdevice 114 may utilize GPS techniques to determine a measurement ofgeographic coordinates of the corresponding user device 110, (IPS device114 may also provide real-time and historic navigation data. Becausesome factors (e.g., atmospheric effects) may reduce the precision of GPSdevice 114, GPS device 114 may return, for example, an error estimatealong with the measured geographic location. The measured geographiclocation and error estimate may provide an area (e.g., a radius aroundthe measured geographic location) where the corresponding user device110 may be located associated with a probability that user device 110 isin the measured geographic location.

User devices 110 may also be equipped with, for example, accelerometer116 and/or gyroscope 118. Accelerometer 116 may be capable of measuringa linear and/or angular acceleration of the corresponding user device110 at a given time. Gyroscope 118 may be capable of determining anorientation of user device 110, Accordingly, accelerometer 116 andgyroscope 118 together may be used to determine a direction ofacceleration of user devices 110. Data generated by accelerometer 116and gyroscope 118 may be used (e.g., by DI computing device 102 or userdevices 110) to generate telematics data (e.g., a location, orientation,acceleration, velocity, etc.) of the corresponding user device 110. Suchtelematics data may be used by DI computing device 102 to generate anenhanced measurement of the geographic location of user device 110 todetermine, for example, whether (i) user device 110 is associated with auser who is a. driver of a vehicle for a shared trip, (ii) user device110 is associated with a user who is a passenger of the vehicle for theshared trip, and/or (iii) user device 110 is associated with a user whois another driver driving closely to the vehicle of the shared tripe.g., the vehicle with user devices 110 being analyzed by DI computingdevice 102).

For example, DI computing device 102 may determine (e.g., using datafrom (IPS device 114, accelerometer 116, and/or gyroscope 118) that twoor more user devices 110 are traveling in the same vehicle togetherbased upon a determination that, over time, the two or more user devices110 have the same direction of travel, and the two or more user devices110 remain constant with respect to the direction of travel. That is, DIcomputer device 102 may determine that the two or more users associatedwith the two or more user devices 110 are participants in a shared trip.DI computing device 102 may further determine one user device 110 is onaverage one meter to the right of and zero meters behind another userdevice 110. In some embodiments, DI computing device 102 may generate amap depicting the relative position of user devices 110 determined to bein the same vehicle.

In some embodiments, DI computing device 102 may determine that two ormore user devices 110 are traveling in the same vehicle for a certainperiod of time (e.g., during a sub-trip, as defined above). A first userdevice 110 may have a certain direction of travel over a period of time,thereby creating a series of relative positions. A second user device110 may also have a certain direction of travel over a period of time,thereby creating another series of relative positions. DI computingdevice 102 may receive the series of relative positions for each userdevice 110 and determine overlap between the two series of relativepositions, in one example, a shared trip may be identified if anoverlapping distance between the two series of relative positions isless than the distance of at least one of the two series of relativepositions. For example, the shared trip (e.g., the sub-trip of the totaltrip) may be identified as the overlap between the series of relativepositions e.g., a route or distance of travel) of the first user device110 and the series of relative positions of the second user device 110.

In some embodiments, DI computing device 102 may determine which userdevice 110 is associated with the driver of the vehicle during a sharedtrip. For example, a first user device 110 may be determined to beassociated with the driver of the vehicle if the first user device 110has no overlap with any other user devices 110 (e.g., the first userdevice 110 is not associated with a shared trip). If the relativepositions of the first user device 110 start to overlap with therelative positions of a second user device 110, DI computing device 102may determine that a sub-trip is shared between the user associated withthe first user device 110 and the user associated with the second userdevice 110. Further, DI computing device 102 may determine that thedriver of the vehicle is still associated with the first user device110. For example, since the shared sub-trip is shorter than the trip ofthe user associated with the first user device 110, DI computing devicemay determine that the driver of the whole trip, including the sharedsub-trip, is associated with the first user device 110. For example, DIcomputing device 102 may determine that the driver associated with thefirst user device 110 picked up a passenger associated with the seconduser device 110 and that the driver associated with the first userdevice 110 is still the driver. Further, for example, if the relativepositions of the first user device 110 and the second user device 110start to overlap but the first user device 110 is determined to be in adifferent position during the shared sub-trip with the second userdevice 110 than at the start of the trip, DI computing device 102 maydetermine that the user associated with the second user device is thedriver and that the user associated with the first user device 110 isnow the passenger. Further, for example, if the relative positions ofthe first user device 110 and the second user device 110 start a tripoverlapping but then the relative positions stop overlapping the userassociated with the second user device 110 is dropped off), DI computingdevice 110 may determine that the driver is the user associated with thefirst user device 110 for the duration of the trip (including thesub-trip with the second user device 110).

In some embodiments, DI computing device 102 may determine a driver of avehicle based upon highest driving probability data. DI computing device102 may determine that a first user device 110 and a second user device110 are traveling in the same vehicle for a certain period of time basedupon received data (e.g., geographic coordinates and timestamp data fromuser devices 110). For the shared trip, DI computing device 102. maydetermine which user device 110 is associated with the user who is theactual driver based upon comparing historic and current drivercharacteristics and/or behavior data (e.g., based upon telematics data).For example, DI computing device 102 may compare historic drivercharacteristics and/or behavior data (e.g., from user devices 110 and/orstored in database 108) of the user associated with the first and seconduser devices 110 with current driver characteristics and/or behaviordata (e.g., from user devices 110) to determine which user is thedriver. That is, if the historical characteristics and behavior data ofthe user associated with the first user device shows that the user is avery safe driver and the current telematics data shows erratic driving,DI computing device 102 may determine that there is a high probabilitythat the user associated with the first user device 110 is not thedriver and that the driver is the user associated with the second userdevice 110. DI computing device 102 may determine the driver for tripsand/or sub-trips of a shared trip. Based upon all gathered data (e.g.,different current driving characteristics/behavior and/or different userdevices 110 determined to be involved with the trip and sub-trips), DIcomputing device 102 may designate a different driver for each sub-tripof the shared trip.

In sonic embodiments, DI computing device 102 may determine that twouser devices 110 are traveling in the same vehicle based upon adetermination that, over time, the two user devices 110 are sufficientlyproximate to each other and have the same direction of travel. DIcomputing device 102 may then use telematics data to determine arelative position of one user device 110 with respect to the other userdevice 110.

In some embodiments, DI computing device 102 may utilize machinelearning techniques to determine the position of the user devices 110based upon telematics data. For example, DI computing device 102 mayidentify a certain pattern in telematics data as indicative of a firstuser device 110 having a certain position relative to a second userdevice 110. When DI computing device 102 receives telematics data thatmatches such a pattern, DI computing device 102 may determine therelative position of the user devices 110 based upon the pattern overtime. In some embodiments, DI computing device 102 may utilize, forexample, the machine learning techniques to determine a probability thata user associated with the first user device 110 and a user associatedwith the second user device 110 corresponds to the driver of vehicle. DIcomputing device 102 may then identify the driver as the user associatedwith the user device 110 having the highest probability of correspondingto the driver of the vehicle. For example, DI computing device 102 maydetermine, based upon a determined relative position of the first userdevice 110 and the second user device 110, that the first user device110 has an 80 percent chance of corresponding with a driver of thevehicle, that the second user device 110 has a 10 percent chance ofcorresponding with the driver, and that there is a 10 percent chancethat both user devices 110 do not correspond with the driver, DIcomputing device 102 may accordingly identify the first user device 110as corresponding to the driver of the vehicle.

In some embodiments, DI computing device 102 may verify theidentification of the driver. For example, DI computing device 102 maytransmit a verification message to users associated with user devices110 (e.g., via a text message, a push notification, and/or via a mobileapplication running on user devices 110). The verification message mayonly be sent to user device 110 associated with the user that DIcomputing device 102 has determined is most probably the driver, and/orthe verification message may be sent to each user device 110 associatedwith the determined shared trip. For example, the verification messagemay request that the probable driver verify that they are the driverand/or the verification message may request that each user of a sharedtrip indicate whether they are the driver or a passenger. In someembodiments, DI computing device 102. may use responses to theverification messages to improve a machine learning model used todetermine the relative position of user devices 110 and/or identify userdevice 110 associated with the driver.

In some example embodiments, DI computing device 102 may be used toimplement a usage-based insurance (UBI) platform and/or may beassociated with client computer device 112 that implements the UBIplatform. In UBI policies of UBI platforms, insurance premiums maycorrespond to driving behaviors and/or characteristics of users (e.g.,as determined by telematics data from user devices 110). It is thusimportant to determine when a. user is actually driving a vehicle andwhen the user is merely a passenger of a vehicle. By identifying adriver of a vehicle for a shared trip, DI computing device 102 assistsin ensuring that telematics data collected for shared trips areassociated with only the determined driver of the vehicle, and not thepassengers of the vehicle.

EXEMPLARY CLIENT COMPUTING DEVICE

FIG. 2 depicts an example configuration of a computer system 200 thatincludes a client computing device 202 that may be used with DI computersystem 100 shown in FIG. 1. Client computing device 202 may be, forexample, at least one of user devices 110 and/or client computer device112 (all shown in FIG. 1).

Client computing device 202 may include a processor 205 for executinginstructions. In some embodiments, executable instructions may be storedin a memory area 210. Processor 205 may include one or more processingunits (e.g., in a multi-core configuration). Memory area 210 may be anydevice allowing information such as executable instructions and/or otherdata to be stored and retrieved. Memory area 210 may include one or morecomputer readable media.

In example embodiments, client computing device 202 may also include atleast one media output component 215 for presenting information to auser 201. Media output component 215 may be any component capable ofconveying information to user 201. In some embodiments, media outputcomponent 215 may include an output adapter such as a video adapterand/or an audio adapter. An output adapter may be operatively coupled toprocessor 205 and operatively couplable to an output device such as adisplay device (e.g., a liquid crystal display (LCD), light emittingdiode (LED) display, organic light emitting diode (OLED) display,cathode ray tube (CRT) display, “electronic ink” display, or a projecteddisplay) or an audio output device (e.g., a speaker or headphones).Media output component 215 may be configured to, for example, display analert message identifying a statement as potentially false.

Client computing device 202 may also include an input device 220 forreceiving input from user 201. Input device 220 may include, forexample, a keyboard, a pointing device, a mouse, a stylus, a touchsensitive panel (e.g., a touch pad or a touch screen), a gyroscope, anaccelerometer, a position detector, or an audio input device. A singlecomponent such as a touch screen may function as both an output deviceof media output component 215 and input device 220.

Client computing device 202 may also include a communication interface225, which can be communicatively coupled to a remote device such as DIcomputing device 102 (shown in FIG. 1). Communication interface 225 mayinclude, for example, a wired or wireless network adapter or a wirelessdata transceiver for use with a mobile phone network (e.g., GlobalSystem for Mobile communications (GSM), 3G, 4G or Bluetooth) or othermobile data network (e.g., Worldwide Interoperability for MicrowaveAccess (WIMAX)).

Stored in memory area 210 may be, for example, computer-readableinstructions for providing a. user interface to user 201 via mediaoutput component 215 and, optionally, receiving and processing inputfrom input device 220. A user interface may include, among otherpossibilities, a web browser and client application. Web browsers mayenable users, such as user 201, to display and interact with media andother information typically embedded on a web page or a website.

Memory area 210 may include, but is not limited to, random access memory(RAM) such as dynamic RAM (DRAM) or static RAM (SRAM), read-only memory(ROM), erasable programmable read-only memory (EPROM), electricallyerasable programmable read-only memory (EEPROM), and non-volatile RAM(NVRAM). The above memory types are examples only, and are thus notlimiting as to the types of memory usable for storage of a computerprogram.

EXEMPLARY SERVER SYSTEM

FIG. 3 depicts an example server system 300 that may be used withcomputer system 100, illustrated in FIG. 1. Server system 300 mayinclude a server computer device 301, and server computer device 301 maybe, for example, DI computing device 102 and/or database server 106(shown in FIG. 1).

In example embodiments, server computer device 301 may include aprocessor 305 for executing instructions. Instructions may be stored ina memory area 310. Processor 305 may include one or more processingunits (e.g., in a multi-core configuration) for executing instructions.The instructions may be executed within a variety of different operatingsystems on server computer device 301, such as UNIX, LINUX, MicrosoftWindows®, etc. It should also be appreciated that upon initiation of acomputer-based method, various instructions may be executed duringinitialization. Some operations may be needed in order to perform one ormore processes described herein, while other operations may be moregeneral and/or specific to a particular programming language (e.g., C,C#, C++, Java, or other suitable programming languages, etc.).

Processor 305 may be operatively coupled to a communication interface315 such that server computer device 301 is capable of communicatingwith a remote device such as another server computer device 301, DIcomputing device 102, user devices 110, and/or client computer device112 (all shown in FIG. 1). For example, communication interface 315 mayreceive requests from user devices 110 and/or client computer devices112 via the Internet.

Processor 305 may also be operatively coupled to a storage device 317,such as database 108 (shown in FIG. 1). Storage device 317 may be anycomputer-operated hardware suitable for storing and/or retrieving data.In some embodiments, storage device 317 may be integrated in servercomputer device 301. For example, server computer device 301 may includeone or more hard disk drives as storage device 317. In otherembodiments, storage device 317 may be external to server computerdevice 301 and may be accessed by a plurality of server computer devices301. For example, storage device 317 may include multiple storage unitssuch as hard disks or solid state disks in a redundant array ofinexpensive disks (RAID) configuration. Storage device 317 may include astorage area network (SAN) and/or a network attached storage (NAS)system.

In some embodiments, processor 305 may be operatively coupled to storagedevice 317 via a storage interface 320. Storage interface 320 may be anycomponent capable of providing processor 305 with access to storagedevice 317. Storage interface 320 may include, for example, an AdvancedTechnology Attachment (ATM adapter, a Serial ATA (SATA) adapter, a SmallComputer System Interface (SCSI) adapter, a RAID controller, a SANadapter, a network adapter, and/or any component providing processor 305with access to storage device 317.

Memory area 310 may include, but is not limited to, random access memory(RAM) such as dynamic RAM (DRAM) or static RAM (SRAM), read-only memory(ROM), erasable programmable read-only memory (EPROM), electricallyerasable programmable read-only memory (EEPROM), and non-volatile RAM(NVRAM). The above memory types are examples only, and are thus notlimiting as to the types of memory usable for storage of a computerprogram.

Processor 305 may execute computer-executable instructions forimplementing aspects of the disclosure. In some embodiments, processor305 may be transformed into a special purpose microprocessor byexecuting computer-executable instructions or by otherwise beingprogrammed, as described below in more detail with regard to FIGS. 4,5A, and 5B.

EXEMPLARY METHOD FOR USER DATA COLLECTION

FIG. 4 depicts an example method 400 for collecting user data,designating a driver of a shared trip based upon the collected userdata, and adjusting usage-based insurance (UBI) rates accordingly.Method 400 may be performed by DI computing device 102 in conjunctionwith user devices 110 (shown in FIG. 1).

Method 400 may include collecting 402, by a first user device (e.g.,user device 110 illustrated in FIG. 1) and collecting 404, by a seconduser device (e.g., user device 110 illustrated in FIG. 1) a plurality ofmeasurements during a trip. A trip may include the traveling from pointA to point B ^(by,) a vehicle a car, truck, motorcycle, or the like), Inanother embodiment, a trip may include intermediate stops between pointsA and. B (e.g., sub-trips). In some embodiments, the plurality ofmeasurements during the trip may include geographic location, timestampdata, telematics data corresponding to the measured geographic location,and driver designation information. In some embodiments, before, during,or after a trip, a user may designate themselves as “driver” or“passenger.” in other embodiments, DI computing device 102 (shown inFIG. 1) may determine the driver for the trips and sub-trips.

Method 400 may further include receiving 406 collected trip data at DIcomputing device 102. DI computing device 102 may receive trip datameasurements from a plurality of user devices 110. The received tripdata measurements may then be stored for later processing andclassification. In some embodiments, trip data may be stored in adatabase, such as database 108, illustrated in FIG. 1. In anotherembodiment, trip data may be stored in a cache for quick retrieval.

Method 400 may further include classifying 408 the received trip data.In some embodiments, received trip data may be self-identified. Forexample, a user may identify that, during one or more specific trips orsub-trips, the user was a driver or a passenger. In some embodiments,the user may not have signified whether they were a driver or apassenger. In these instances, DI computing device 102 may assign aprobability that each user (e.g., the user associated with the first andsecond user devices) was the driver during a certain trip. In someembodiments, further processing may be undertaken of all received datato determine whether a shared trip with other users has occurred. Thisfurther processing is expanded upon in conjunction with FIGS. 5A and 5B.

Method 400 may include adjusting 410 a user's driver insurance premium.In an instance where a user subscribes to usage-based insurance,telematics data gathered may adjust a driver's premiums. For example,with a usage-based insurance policy, an insurance premium corresponds toa driver's actual driving behavior. Safer driving habits detected by thetelematics data, such as avoiding excessive speed or hard brakingevents, may cause a user's insurance premium to be discounted.

EXEMPLARY COMPUTER-IMPLEMENTED METHOD FOR CLASSIFYING NEW TRIP DATA

FIGS. 5A and 5B depict an example method 500 for classifying new tripdata as possibly part of a shared trip based upon collected user data(e.g., from user devices 110, illustrated in FIG. 1). Method 500 may beperformed by DI computing device 102 (shown in FIG. 1).

Method 500 may include receiving 502 new trip data captured by a userdevice (e.g., user device 110) for processing as described herein andabove. New trip data may include a trip identifier and a user identifierassociated with at least one user. As described above, new trip data mayalso include geographical data (e.g., GPS data), timestamp data, userindications (e.g., driving, not driving, unknown), and telematics datain accordance with the geographical data.

Method 500 may further include querying 504 a database, such as database108 (shown in FIG. 1), by DI computing device 102. Database 108 may bepopulated with past trip data of users, for example, users of theusage-based insurance platforms and policies. In some embodiments,querying 504 may include generating a query to select relevant pasttrips based upon certain parameters. For example, a query may be madefor all trips made by users within the past 30 days. In anothernon-limiting example, a query may be made for all trips made by userswithin the past 30 days and within a certain geographical location(e.g., zip code, state, region, etc.). Next, method 500 may includeselecting 506 all logged trips with end times occurring after the starttime of the new trip data. This step may eliminate all trips that cannotbe a shared trip with the new trip data since a time overlap does notexist. Next, method 500 may further include calculating 508 start andend points of all selected trips. The start and end points may include amargin of error. For example, if a first user device starts a trip attime X, such as 12:00:00 PM, and a second user device starts a trip attime Y, such as 12:00:05, the first and second user device's trips couldboth be selected. In one embodiment, the start or end time variables maybe within a certain time window of the new trip data's start or end timevariables. Following the example, the start time window may be set at 20seconds and, if the new trip data is associated with time Y, the windowmay be between 11:59:55 and 12:00:15. In some embodiments, the timewindow may be ten seconds, 20 seconds, 1 minute, 5 minutes, etc. Aspecific time variable is not meant to be limiting.

Once all logged trips having similar start or end times have beenselected, method 500 may include calculating 508 geographical and/orlocation start/end points for each of the logged trips. For example,calculating 508 may include determining a latitude and longitude foreach start and end point of every logged trip. In another embodiment, astart or end point may include a certain landmark, such as a school or alibrary. All trips having some time overlap as well as similar start andend points may then be selected.

Method 500 may further include performing 510 a distance comparison stepfor each of the selected trips for comparison with the new trip data.Distance comparison may be performed in view of a cutoff value (e.g.,within a fourth or a half of a mile of the starting and ending points ofthe new trip). In some embodiments, the cutoff value may be based upontemporal GPS accuracy. If the distance of a certain trip is not withinthe cutoff value, the comparison may not be found to be similar 512 andtherefore may not qualify to be a shared trip 514 with the new tripdata. If the distance of a certain trip is within the cutoff value, thecomparison may be found to be similar 512 (e.g., and the trip may bedetermined to be a shared trip), and method 500 may continue. Performing510 the distance comparison may be repeated for each logged trip forcomparison with the new trip data.

Method 500 may include, once distance comparison is performed 510,determining 516 if at least one user has self-identified as the driverduring the shared trips. In an example embodiment, at least one of theusers identified to be part of a shared trip may self-identify as adriver. This self-identification may be performed via a mobileapplication installed on the user's device (e.g., user device 110). Inone embodiment, a user may indicate that they are driving prior to atrip. In another embodiment, a user may indicate that they are drivingduring a trip. In yet another embodiment, a user may indicate that theywere a driver for a recently completed trip. Process 500 continues ontoFIG. 5B. In the event that a user did self-identify as a driver,RESULT=YES in step 518, the user may be classified as the driver for theshared trip. All other users of the shared trips may then be classifiedas not driving. In one embodiment, non-drivers may simply be classifiedas passengers. In another embodiment, non-drivers may be classified as“GUESS-NOT-DRIVING.” Since a user identified as the driver, method 500may then terminate. If a user did not self-identify as a driver,RESULT=NO in step 518, method 500 may advance.

Method 500 may further include determining 522 if at least one tripamong the shared trips is longer than others. In the event that at leastone of the logged trips is longer in distance traveled, elapsed time, ora combination thereof, it may be concluded that the user associated withthe longer trip started driving and picked up passengers along the way.For example, a user may have started a trip and picked up differentpassengers for a carpool. In this example, all passengers of thevehicle, as well as the driver, would have different start times butsimilar, if not the same, end times. Result 524, in this examplescenario, would be “YES.” Method 500 may further include assigning 526‘GUESS-DRIVING’ to the user device associated with the earliest startingtime and longest driven distance of the shared trip. Further, method 500may include assigning 528 ‘GUESS-NOT-DRIVING’ to the other user devicesassociated with the shared trip. In the event that Result 524=NO, method500 may further include assigning 530 ‘GUESS-DRIVING’ to user deviceswhere the user associated with the user device is determined to have ahigh probability of driving. Probability may be determined in a myriadof ways.

In some embodiments, a driving probability may be determined for eachtrip taken by a user. For example, historical data, telematics data, GPSdata, along with other information related to a user's driving history,may be stored in a user profile. The user profile may be stored in astorage location of driver identification computing device 102, such asdatabase 108, for example. Historical data may include past trips takenby a user, including trips when the user was the driver and when theuser was a passenger. Some trips taken by the user may be identified asfrequent trips. For example, a frequent trip may include a dailycommute, a weekly drive to the supermarket on certain days, or the like.Telematics data may be collected over time with respect to user.Collected data may be used to identify a user, much like a fingerprint.In one example, driving style may be determined based upon brakingevents, sudden or smooth acceleration, and fast/slow cornering, forexample.

EXEMPLARY COMPUTER DEVICE

FIG. 6 depicts a diagram 600 of components of one or more exemplarycomputing devices 610 that may be used in DI system 100 shown in FIG. 1.In some embodiments, computing device 610 may be similar to DI computingdevice 110 (shown in FIG. 1). Database 620 may be coupled with severalseparate components within computing device 610, which perform specifictasks. In this embodiment, database 620 may include user data 622 (e.g.,associated with users associated with user devices 110, shown in FIG.1), insurance data 624 (e.g., insurance premiums and policies related tousage-based insurance platforms), driving data 626 (e.g., drivingcharacteristics, driving behaviors, telematics data, location data, etc.from user devices 110, shown in FIG. 1), and trip data 628 (e.g., data,like start/end times and points, associated with trips and sub-trips,determined shared trips between users, etc.). In some embodiments,database 620 is similar to database 108 (shown in FIG. 1).

Computing device 610 may include the database 620, as well as datastorage devices 630. Computing device 610 may also include a determiningcomponent 640, a calculating component 650, and an identifying component660. Determining component 640 may be configured to determine, basedupon a first plurality of measurements and a second plurality ofmeasurements, that a first user device and a second user device (e.g.,user devices 110, shown in FIG. 1) are traveling on the trip, anddetermining, based upon an enhanced geographic location measurement foreach of the first plurality of measurements and for each of the secondplurality of measurements, a predicted position of the second userdevice relative to the first user device with respect to a forwarddirection of travel of a vehicle. Calculating component 650 may beconfigured to calculate, for example, using a Kalman filter, an enhancedgeographic location measurement for each of the first plurality ofmeasurements and each of the second plurality of measurements based uponthe measured geographic location, the error estimate, and the telematicsdata corresponding to each of the first plurality of measurements andsecond plurality of measurements. Identifying component 660 may beconfigured to identify, from among the first user device and the seconduser device, a user device corresponding to a driver based upon thepredicted position of the second user device relative to the first userdevice, the driving characteristics of the current trip compared to thedriving characteristics of the users associated with the first andsecond user devices, etc.

CERTAIN EMBODIMENTS

A driver identification (DI) computing device comprising at least oneprocessor in communication with a memory device may be provided. The atleast one processor may be configured to: associate a first user with afirst user device; associate a second user with a second user device;receive, from the first user device, a first plurality of measurementsperiodically captured at the first user device during a first trip;receive, from the second user device, a second plurality of measurementsperiodically captured at the second user device during a second trip;identify a shared trip based upon the captured first and secondplurality of measurements; and determine, based upon the captured firstand second plurality of measurements, a driver of a vehicle, in responseto the first and second trip being a shared trip.

A further enhancement of the DI computing device may include wherein theat least one processor may further configured to, for identifying ashared trip: calculate a time and distance for each of the first tripand the second trip in response to determining that the first trip has astart time or end time that overlaps with the end time or start time ofthe second trip; calculate an overlapping time and distance between thefirst trip and the second trip; and calculate a distance shared betweenthe first trip and the second trip.

A further enhancement of the DI computing device may include wherein theat least one processor may be further configured to, for identifying ashared trip: classify the first trip and the second trip as a sharedtrip in response to determining that the overlapping distance is lessthan the distance of the first trip or the second trip.

A further enhancement of the DI computing device may include wherein theat least one processor may be further configured to, for determining adriver: designate at least one of the first and second users as a driverof the shared trip based upon at least one of, and in response to: thefirst or second users self-identifying as the driver; to at least one ofthe trips taken being longer than the other, designate the user of thelonger trip as the driver; and at least one of the first and secondusers having a higher driving probability for the shared trip.

A further enhancement of the DI computing device may include wherein thehigher driving probability may be based at least in part on historicaldata stored in a user profile of the first or second users.

A further enhancement of the DI computing device may include whereineach of the first plurality of measurements and each of the secondplurality of measurements includes timing data, geographical locationdata, and telematics data.

A further enhancement of the DI computing device may include wherein thefirst plurality of measurements and the second plurality of measurementsmay be collected by one or more sensors attached to a vehicle, the firstuser device, the second user device, or a combination thereof.

In another aspect, a computer-based method for designating a driver of ashared trip between two or more users may be provided. Thecomputer-based method may include collecting, by a plurality of userdevices, a plurality of measurements for a plurality of trips;receiving, at a driver identification (DI) computing device, theplurality of measurements; and designating, by the DI computing device,a driver based upon the plurality of measurements. The computer-basedmethod may include additional, less, or alternate functionality,including that discussed elsewhere herein.

A further enhancement of the computer-based method may include: storingthe plurality of measurements in a storage device in communication withthe DI computing device; associating the plurality of measurements withrespective users of the two or more users; and creating a user profilefor each of the two or more users based upon the plurality ofmeasurements.

A further enhancement of the computer-based method may include whereinthe plurality of measurements include at least one or more of GPS data,time data, and telematics data.

A further enhancement of the computer-based method may include whereindesignating a driver further comprises: identifying a shared tripbetween a plurality of users associated with two or more respective userdevices of the plurality of user devices based upon the plurality ofmeasurements.

A further enhancement of the computer-based method may include whereinidentifying a shared trip further comprises: calculating an overlappingtime and distance for each of the plurality of users based upon theplurality of measurements; and classifying two or more of the pluralityof trips as a shared trip in response to the calculated overlappingdistance being less than a distance of one of the two or more of theplurality of trips.

In yet another aspect, at least one non-transitory computer-readablestorage media having computer-executable instructions embodied thereonmay be provided. The instructions, when executed by at least oneprocessor, may cause the processor to: receive trip data from aplurality of user devices, wherein each user device is associated with auser of a plurality of users; identify a first user of the plurality ofusers having trip data that overlaps with trip data of a second user ofthe plurality of users; classify at least a portion of the trip data ofthe first and second users as a shared trip; and designate at least oneof the first and second users as a driver of the shared trip. Thecomputer-executable instructions may include additional, less, oralternate functionality, including that discussed elsewhere herein.

A further enhancement of the computer-readable storage media may includewherein the trip data includes one or more of: GPS-based distance, time,and location data.

A further enhancement of the computer-readable storage media may includewherein the step to designate at least one of the first and second usersas a driver of the shared trip further comprises: retain driverdesignation for the first or second user in response to determining thatthe first or second user was previously designated as driver.

A further enhancement of the computer-readable storage media may includewherein the step to designate at least one of the first and second usersas a driver of the shared trip further comprises: designate the firstuser as driver in response to determining that the GPS-based distance ofthe first user trip is longer than the second user trip.

A further enhancement of the computer-readable storage media. mayinclude wherein the step to designate at least one of the first andsecond users as a driver of the shared trip further comprises: designatethe second user as driver in response to determining that the GPS-baseddistance of the second user trip is longer than the first user trip.

A further enhancement of the computer-readable storage media may includewherein the step to designate at least one of the first and second usersas a driver of the shared trip further comprises: designate at least oneof the first user and the second user as driver in response to driverprobability data associated with each of the first user and the seconduser, wherein the driver with higher probability is designated driver ofthe shared trip.

A further enhancement of the computer-readable storage media may includewherein driver probability data is based upon historical data associatedwith each of the first and second users.

A further enhancement of the computer-readable storage media may includewherein historical data comprises past trip data including telematicsdata, GPS-based distance data, and timing data.

EXAMPLES OF ADDITIONAL CONSIDERATIONS

As will be appreciated based upon the foregoing specification, theabove-described embodiments of the disclosure may be implemented usingcomputer programming or engineering techniques including computersoftware, firmware, hardware or any combination or subset thereof. Anysuch resulting program, having computer-readable code, may be embodiedor provided within one or more computer-readable media, thereby making acomputer program product, e.g., an article of manufacture, according tothe discussed embodiments of the disclosure. The computer-readable mediamay be, for example, but is not limited to, a fixed (hard) drive,diskette, optical disk, magnetic tape, semiconductor memory such asread-only memory (ROM), and/or any transmitting/receiving medium such asthe Internet or other communication network or link. The article ofmanufacture containing the computer code may be made and/or used byexecuting the code directly from one medium, by copying the code fromone medium to another medium, or by transmitting the code over anetwork.

These computer programs (also known as programs, software, softwareapplications, “apps”, or code) include machine instructions for aprogrammable processor, and can be implemented in a high-levelprocedural and/or object-oriented programming language, and/or inassembly/machine language. As used herein, the terms “machine-readablemedium” “computer-readable medium” refers to any computer programproduct, apparatus and/or device magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The “machine-readable medium” and “computer-readable medium,” however,do not include transitory signals. The term “machine-readable signal”refers to any signal used to provide machine instructions and/or data toa programmable processor.

As used herein, a processor may include any programmable systemincluding systems using micro-controllers, reduced instruction setcircuits (RISC), application specific integrated. circuits (ASICs),logic circuits, and any other circuit or processor capable of executingthe functions described herein. The above examples are examples only,and are thus not intended to limit in any way the definition and/ormeaning of the term “processor.”

As used herein, the terms “software” and “firmware” are interchangeable,and include any computer program stored in memory for execution by aprocessor, including RAM memory, ROM memory, EPROM memory, EEPROMmemory, and non-volatile RAM (NVRAM) memory. The above memory types areexamples only, and are thus not limiting as to the types of memoryusable for storage of a computer program.

In one embodiment, a computer program is provided, and the program isembodied on a computer readable medium. In an example embodiment, thesystem is executed on a single computer system, without requiring aconnection to a sever computer. in a further embodiment, the system isbeing run in a Window® environment (Windows is a registered trademark ofMicrosoft Corporation, Redmond, Wash.). In yet another embodiment, thesystem is run on a mainframe environment and a UNIX® server environment(UNIX is a registered trademark of X/Open Company Limited located inReading, Berkshire, United Kingdom). The application is flexible anddesigned to run in various different environments without compromisingany major functionality. In some embodiments, the system includesmultiple components distributed among a plurality of computing devices.One or more components may be in the form of computer-executableinstructions embodied in a computer-readable medium. The systems andprocesses are not limited to the specific embodiments described herein.In addition, components of each system and each process can be practicedindependent and separate from other components and processes describedherein. Each component and process can also be used in combination withother assembly packages and processes.

As used herein, an element or step recited in the singular and precededby the word “a” or “an” should be understood as not excluding pluralelements or steps, unless such exclusion is explicitly recited.Furthermore, references to “example embodiment” or “one embodiment” ofthe present disclosure are not intended to be interpreted as excludingthe existence of additional embodiments that also incorporate therecited features.

The patent claims at the end of this document are not intended to beconstrued under 35 § 112(f) unless traditional means-plus-functionlanguage is expressly recited, such as “means for” or “step for”language being expressly recited in the claim(s).

This written description uses examples to disclose the disclosure,including the best mode, and also to enable any user skilled in the artto practice the disclosure, including making and using any devices orsystems and performing any incorporated methods. The patentable scope ofthe disclosure is defined by the claims, and may include other examplesthat occur to those skilled in the art. Such other examples are intendedto be within the scope of the claims if they have structural elementsthat do not differ from the literal language of the claims, or if theyinclude equivalent structural elements with insubstantial differencesfrom the literal language of the claims.

1.-20. (canceled)
 21. A computing device for driver identification, thecomputing device comprising: one or more processors; and a memorystoring instructions that, when executed by the one or more processors,cause the one or more processors to: determine whether a first trip by afirst user and a second trip by a second user are a shared trip within avehicle based at least in part upon a first plurality of measurementsfrom a first user device during the first trip and a second plurality ofmeasurements from a second user device during the second trip, whereindetermining whether the first trip and the second trip are the sharedtrip within the vehicle includes determining whether the first user andthe second user are in the vehicle together during the shared trip; andif the first user and the second user have been determined to be in thevehicle together during the shared trip, determine whether the firstuser or the second user is a driver of the vehicle during the sharedtrip based at least in part upon the first plurality of measurements andthe second plurality of measurements.
 22. The computing device of claims21, wherein the instructions, when executed by the one or moreprocessors, further cause the one or more processors to: calculate atime and a distance for each trip of the first trip and the second tripin response to determining that the first trip overlaps with the secondtrip in time; calculate an overlapping time between the first trip andthe second trip; and calculate a shared distance between the first tripand the second trip.
 23. The computing device of claim 22, wherein theinstructions, when executed by the one or more processors, further causethe one or more processors to: classify the first trip and the secondtrip as the shared trip in response to determining that the shareddistance is less than the distance of the first trip or the second trip.24. The computing device of claim 21, wherein the instructions, whenexecuted by the one or more processors, further cause the one or moreprocessors to: designate at least one of the first user and the seconduser as the driver of the shared trip based at least in part upon thefirst user or the second user self-identifying as the driver.
 25. Thecomputing device of claim 21, wherein the instructions, when executed bythe one or more processors, further cause the one or more processors to:designate at least one of the first user and the second user as thedriver of the shared trip based at least in part upon one trip of thefirst trip and the second trip being longer than the other trip, whereinthe first user or the second user of the longer trip is designated asthe driver.
 26. The computing device of claim 21, wherein theinstructions, when executed by the one or more processors, further causethe one or more processors to: designate at least one of the first userand the second user as the driver of the shared trip based at least inpart upon one user of the first user and the second user having a higherdriving probability of being the driver for the shared trip, wherein thehigher driving probability is based upon historical data stored in userprofiles of the first user and the second user.
 27. The computing deviceof claim 21, wherein the instructions, when executed by the one or moreprocessors, further cause the one or more processors to: receive thefirst plurality of measurements from the first user device during thefirst trip; and receive the second plurality of measurements from thesecond user device during the second trip.
 28. A computer-implementedmethod for driver identification, the method comprising: determiningwhether a first trip by a first user and a second trip by a second userare a shared trip within a vehicle based at least in part upon a firstplurality of measurements from a first user device during the first tripand a second plurality of measurements from a second user device duringthe second trip, wherein determining whether the first trip and thesecond trip are the shared trip within the vehicle includes determiningwhether the first user and the second user are in the vehicle togetherduring the shared trip; and if the first user and the second user havebeen determined to be in the vehicle together during the shared trip,determining whether the first user or the second user is the driver ofthe vehicle during the shared trip based at least in part upon the firstplurality of measurements and the second plurality of measurements. 29.The computer-implemented method of claim 28, further comprising:calculating a time and a distance for each trip of the first trip andthe second trip in response to determining that the first trip overlapswith the second trip in time; calculating an overlapping time betweenthe first trip and the second trip; and calculating a shared distancebetween the first trip and the second trip.
 30. The computer-implementedmethod of claim 29, further comprising: classifying the first trip andthe second trip as the shared trip in response to determining that theshared distance is less than the distance of the first trip or thesecond trip.
 31. The computer-implemented method of claim 28, furthercomprising: designating at least one of the first user and the seconduser as the driver of the shared trip based at least in part upon thefirst user or the second user self-identifying as the driver.
 32. Thecomputer-implemented method of claim 28, further comprising: designatingat least one of the first user and the second user as the driver of theshared trip based at least in part upon one trip of the first trip andthe second trip being longer than the other trip, wherein the first useror the second user of the longer trip is designated as the driver. 33.The computer-implemented method of claim 21, further comprising:designating at least one of the first user and the second user as thedriver of the shared trip based at least in part upon one user of thefirst user and the second user having a higher driving probability ofbeing the driver for the shared trip, wherein the higher drivingprobability is based upon historical data stored in user profiles of thefirst user and the second user.
 34. The computer-implemented method ofclaim 21, further comprising: receiving the first plurality ofmeasurements from the first user device during the first trip; andreceiving the second plurality of measurements from the second userdevice during the second trip.
 35. A non-transitory computer-readablemedium storing instructions for driver identification, the instructions,when executed by one or more processors of a computing device, cause thecomputing device to: determine whether a first trip by a first user anda second trip by a second user are a shared trip within a vehicle basedat least in part upon a first plurality of measurements from a firstuser device during the first trip and a second plurality of measurementsfrom a second user device during the second trip, wherein determiningwhether the first trip and the second trip are the shared trip withinthe vehicle includes determining whether the first user and the seconduser are in the vehicle together during the shared trip; and if thefirst user and the second user have been determined to be in the vehicletogether during the shared trip, determine whether the first user or thesecond user is a driver of the vehicle during the shared trip based atleast in part upon the first plurality of measurements and the secondplurality of measurements.
 36. The non-transitory computer-readablemedium of claim 35, wherein the instructions that cause the computingdevice to determine whether the first user or the second user is thedriver of the vehicle further cause the computing device to: designatethe first user or the second user as the driver; and retain the driverdesignation for the first user or the second user in response todetermining that the first user or the second user was previouslydesignated as the driver.
 37. The non-transitory computer-readablemedium of claim 36, wherein the instructions that cause the computingdevice to designate the first user or the second user as the driverfurther cause the computing device to: designate the first user as thedriver in response to determining that a GPS-based distance of the firsttrip is longer than a GPS-based distance of the second trip.
 38. Thenon-transitory computer-readable medium of claim 36, wherein theinstructions that cause the computing device to designate the first useror the second user as the driver further cause the computing device to:designate the second user as the driver in response to determining thata GPS-based distance of the second trip is longer than a GPS-baseddistance of the first trip.
 39. The non-transitory computer-readablemedium of claim 36, wherein the instructions that cause the computingdevice to designate the first user or the second user as the driverfurther cause the computing device to: designate the first user or thesecond user as the driver in response to driver probability dataassociated with each user of the first user and the second user, whereinthe first user or the second user with a higher probability of being thedriver is designated as the driver of the shared trip.
 40. Thenon-transitory computer-readable medium of claim 35, wherein theinstructions, when executed by the one or more processors, further causethe computing device to: receive the first plurality of measurementsfrom the first user device during the first trip; and receive the secondplurality of measurements from the second user device during the secondtrip.